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,  Carnegie  Mellon 
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Agenda 


Defining  agile 

Research  study:  context  and  questions 

What  we  have  learned  so  far:  The  current  state 

•  Case  studies  of  Internet  Software  Development 

•  Discovery  Colloquium 

Where  we’re  going:  The  future  state 

•  propagating  agile  approaches,  scaling,  self-organizing 
systems  (i.e.,  nonlinear,  adaptive) 

Challenges,  dilemmas,  and  conundrums 

•  process,  discipline,  and  governance 
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Defining  Agiie 


Merriam  Webster  (2004)  defines  agile  from  the  Middle 
French  and  from  the  Latin  agilis,  from  agere  to  drive,  act 
as  "1:  marked  by  ready  ability  to  move  with  quick  easy 
grace  [and  ]  2:  having  a  quick  resourceful  and  adaptable 
character  <an  agile  mind>."  Agility  is  defined  as  "the 
quality  or  state  of  being  agile:  NIMBLENESS,  DEXTERITY 
<played  with  increasing  agility>." 

Four  key  attributes 

•  speed:  quick,  fast 

•  nimble:  able  to  improvise,  use  patterns  creatively  to  construct  new 
solutions  on  the  fly,  flexible 

•  adaptable:  responsive  (sense  and  respond),  dynamic  and 
interactive  in  response  to  a  customer  or  to  changing  circumstances. 

•  resourceful:  thoughtful  or  exhibiting  some  discipline  (Note:  not  the 
same  as  traditional  “command  and  control”  approach  with  defined, 
formal  procedures) 
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The  Agile  Manifesto  says.... 


•  Top  level: 

“We  are  uncovering  better  ways  of  developing  software  by  doing  it 
and  helping  others  do  it.” 

•  2"^^  level: 

“Through  this  work,  we  have  come  to  value... 


Individuals  and  actions 

over 

processes  and  tools. 

Working  software 

over 

comprehensive  documentation. 

Customer  collaboration 

over 

contract  negotiation 

Responding  to  change 

over 

following  a  plan. 

That  is,  while  there  is  value  in  the  items  on  the  right,  we  value  the 
items  on  the  left  more.”  wwwAgileAlliance.org 
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The  Current  Ciimate 


Formula  for  gaining  and  controlling  market  share  is  changing 

•  In  the  past,  a  company  positioned  itself  along  a  single  dimension. 

•  Now,  competitive  edge  goes  to  companies  that  deliver  better 
products,  faster  and  cheaper. 


time  to 
market 


cost 
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What  does  “internet  speed”  mean 
anyway? 


“The  pressure  to  release  new  software  products  faster 
and  faster  has  grown  over  the  years  ...ten  years  ago, 
development  cycles  of  24-36  months  were  typical, 
today,  a  year  to  18  months  development  cycle  is  normal 
for  software  products ... 

Within  “emerging  fields  such  as  electronic  commerce 
and  Web  portal  sites  competing  on  Internet  time  demand 
significant  product  and  feature  changes  every  three  to 
six  months” 

Cusumano,  1998 
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Source:  Michel  Baudin,  3/16/99.  Lean  production:  the  end  of  management  whack-a-mole. 
http://www.mmt-inst.com/End_of_management_whack_a_mole.html 


Carnegie  Mellon 
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Whack  a  Moie?! 
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Key  Research  Questions 


How  do  firms  develop  fast  cycle  time  software? 

Is  “Internet  speed”  software  development  really  different  from 
traditional  software  development? 

How  can  both  quality  and  agility  be  achieved  in  fast-paced 
software  development? 

What  development  practices  are  effective  in  this  rapid  pace 
environment? 
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Research  Team 


Richard  Baskerville  and  Balasubramanian  Ramesh 
Department  of  Computer  Information  Systems, 
Georgia  State  University 

Linda  Levine 

Software  Engineering  Institute, 

Carnegie  Mellon  University 

Jan  Pries-Heje 

The  IT  University  of  Copenhagen 
Sandra  Slaughter 

Graduate  School  of  Industrial  Administration, 
Carnegie  Mellon  University 
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A  Muiti-Phase  Approach 

PHASE  1:  Case  studies  conducted  in  nine  firms 


PHASE  2:  Discovery  colloquium  to  synthesize  knowledge  on 
principles  and  practices 

PHASE  3:  Longitudinal  revisit  to  firms  after  two  years 

The  firms  range  in  size  from  10  employees  to  more  than  300,000 

•  new  Internet  software  dot.coms  &  established  brick  &  mortar  firms 

•  private  &  public  sectors: 

-  software  houses  -  financial  services  and  insurance 

-  courier  services  -  business  &  consulting  services 

-  travel  -  media 

-  utilities 
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Phase  1:  Detaiied  interviews 


With: 

•  senior  managers,  project  managers 

•  software  engineers,  QA  engineers 

Questions  on: 

•  demographics  on  organization  &  interviewees 

•  “Internet  speed” 

•  products  &  business  strategy 

•  quality 

•  teaming  &  people 

•  development  methods  &  tools 

•  issues,  problems  &  challenges 
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Phase  1:  Resuits 


Drivers  of  Internet  speed  development  practices 
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Phase  2:  Discovery  Coiioquium 


Rich  mix  of  participants;  maximum  exchange  of  ideas 

Leverage  forward-looking  methodologies 

•  “Future  search”  approaches  to  system  learning 

-  form  of  action  research 

-  “bring  the  whole  system  in  the  room” 

•  “Difference  questioning” 

-  identify  relevant  differences  among  participants 

-  “when  members  of  a  group  question  differences  (they)  generate 
new  information”  (Goldstein,  1994) 

•  “Creative  abrasion” 

-  “creates  a  collision  of  ideas  within  a  climate  of  social  cohesion” 

-  result:  original  and  innovative  ideas  (Leonard,  1995) 
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Phase  2:  Coiioquium  Approach 


Process 

•  inclusion  exercise:  metaphors 

•  “talking  circles” 

•  breakout  groups:  on  core  issues 

1.  Hypothesis  Testing 

-  develop  hypotheses,  select  focus 

2.  Difference  Questioning 

-  assumption  surfacing 

-  identify  principles  &  promising 
practices  (patterns  of  commonality  or 
difference  across  the  assumptions) 

3.  Futuring,  scenario  deveiopment 

-  emerging  conditions  &  impacts 

Facilitators  and  scribes 


Analysis  and  Results 

•  materials  transcribed 

•  transcripts  analyzed 

•  technical  report  drafted,  distributed 

•  feedback  solicited 

Findings  emerge 

•  participants’  insights 

•  post-colloquium  comparison  of 
principles  underlying  agile  and 
traditional  methods 
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Breakout  Group:  What  is  different  about  agiie 
methods? 

General  observations 

•  popular  claims  that  agile  methods  are  radically  new  and  the 
best  approach  to  Internet  software  development 

•  key  elements 

-  collaborative  work 

-  incremental  development 

-  evolutionary  life  cycles  within  a  strategy 

-  strong  customer  communication 

•  many  of  these  elements  embodied  in  extreme  Programming 

•  effectiveness  lies  in  people,  not  process  -  heroes  rewarded 
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Hypotheses:  Agiie  Methods 


H1.  Agile  methods  are  more  effective  than  traditional  methods. 
H2.  Agile  methods  are  not  different  than  traditional  methods. 
H3.  Partially  implementing  key  agile  practices  will  lead  to 
project  failure. 

H4.  Agile  methods  require  good  people  to  be  successful. 

H5.  Agile  methods  are  needed  for  Internet  speed  development 
because  it  is  fundamentally  different  from  traditional. 

H6.  Agile  methods  are  effective  when  the  time  horizon  is  short, 
and  not  as  effective  over  the  long  term. 

H7.  Agile  methods  aren’t  really  new  perse,  but  their 
implementation  is  extreme. 
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Comparing  Agiie  &  Traditionai  Principies 


What  principles  overlap? 

•  common  principles  across  agile  and  traditional  methods 

What  agile  principles  are  missing? 

•  those  traditional  principles  with  no  apparent  agile  equivalent 

What  traditional  principles  are  missing? 

•  those  agile  principles  with  no  apparent 
equivalent  traditional  principle 


xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

Trad.  Agile 
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Overiapping  Principies 

Flexibility 

Understanding  functional  requirements 
Responding  to  change 
Learning  from  experience 


xxxxxx 


xxxxxx 


xxxxxx 

xxxxxx 


Trad.  Agile 
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Missing  Principies 


Agile  Principles  set  is  missing: 


quantitative  measurement 
interchangeable  components 
complexity  &  uncertainty 
control 

rigorous  requirements 
specification 

formal  quality  management 
documentation 
component  coupling 
stepwise  assembly 
disciplined  process 


Traditional  Principles  set  is 
missing: 

•  teamwork  &  on-the-fly 
software  process  adaptation 

•  informal  knowledge  exchange 

•  collaboration  &  experience 

•  tailoring  project  practices  to 
environmental  conditions 


xxxxxx 

XXXXXX 

XXXXXX 

XXXXXX 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxxi 

xxxxxx^ 

c 

1 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

Q 

xxxxxx 

xxxxxx 

Trad. 

Agile 

Trad. 

Agile 
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Phase  2:  Summary 


•  Many  principles  of  traditional  methods  consistent  with  an  industrial 
production  paradigm,  or  software  “factory” 

•  Agile  principles  include  many  features  of  a  “job  shop”  environment 

•  Agile  software  development  occurs  in  a  more  informal,  dynamic, 
learning  environment.  Agile  methods  support  shorter  project  life 
cycles  in  order  to  respond  to  complex,  fast-moving,  and  competitive 
marketplaces. 

•  Agile  methods  have  emerged  and  are  used  by  some  organizations 
for  fast-paced  software  development 

-  some  organizations  also  continue  to  develop  software  using 
traditional  methods 

-  some  use  BOTH  agile  methods  and  traditional  methods 

-  parallel  paradigms  for  software  development 
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Phase  3:  Case  Study  Continues 


Two  years  later,  only  five  of  the  original  companies  remained  in 
business  or  were  available  to  participate  in  the  study.  Only  one  of  the 
small  Internet  software  houses  had  survived. 

To  maintain  the  representative  nature  of  the  companies,  we  added  an 
additional  company — a  small  innovative  Internet  software  house.  In  all, 
six  companies  participated  in  Phase  3. 


Re-interviewed  managers  and  staff  using  same  questions  from  Phase 
1  on  strategies,  methods,  tools,  issues,  etc. 

Compared  what  has  changed  and  what  has  not 

•  confirmation  of  which  Internet  speed  practices  prevail 

•  insight  into  how  environmental  contingencies  impact  the  choice  and 
effectiveness  of  Internet  speed  practices 
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Phase  3:  Results 


Less  capital  than  before 
&  More  emphasis 
on  business  model 


Solution  set 

1.  Business 
model 

2.  Different 
projects 

3.  Cost  focus 


Solution  set 

1.  Architecture 

2.  Components/reuse 

3.  Estimation  methods 

4.  QA  &  Testing 

5.  Parallel  development 

6.  Prototyping 

7.  Frequent  releases 


equires  more  quality 
Have  come  to  expect  speed . 


Customer 
needs 


©  2005  Carnegie  Mellon  University 


23 


Cariic^ic  Mellon 

Software  Engineering  institute 


Phase  3:  Summary 


Trade-offs  and  balancing  decisions — a  high-speed  balancing 
game — were  taking  place  at  three  different  levels 

Market:  IT  economy  slowed  the  interest  in  IT  products,  easing  the 
intense  competition  for  human  resources.  Consolidation  of  best 
practice. 

Portfolio:  Business  case  became  the  primary  vehicle  for  selecting 
projects  for  inclusion  or  continuation.  Managers  “cherry  pick”  the  most 
ideal  projects  to  meet  their  customers’  needs. 

Project:  Project  managers  consolidate  product  development  to 
embrace  construction  of  fewer  products.  Major  values  persist,  such  as 
parallel  development,  limited  maintenance  &  documentation,  frequent 
releases  &  other  factors 

-  still  necessary  to  maintain  customer  satisfaction  and  compete 

-  also  noted  for  enabling  quick,  economical  products. 
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Where  are  we  going?  The  Future  State 

•  Use  of  agile  methods  and  agility  is  consistently  associated  with 
software  development  techniques. 

•  Fledgling  signs  of  expansion 

-  contracting  of  the  market  and  tightening  of  resources  has 
contributed  to  increased  complexity  in  the  balancing  game 

-  may  spur  further  growth  for  agile  approaches  in  atypical  areas 

•  Current  state  for  agile  methods  is  still  isolated  and  limited 

-  partial  understanding  of  what  agility  means  for  software 
development  activities. 

-  best  insights  still  achieved  through  discrete  activities — through 
projects  which  exist  like  islands  in  our  organizations 

-  development,  adoption,  knowledge  transfer 
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The  Future 


Optimize  the  current  state.  Loosely  integrate  and  propagate  agile 
approaches. 

•  business  &  technical 

•  leverage  what  we  know;  reinforce  discrete  areas  of  success 

More  radically,  tackle  the  issue  of  scaling  to  investigate  options  and 
opportunities  that  can  span  organizations. 

•  ask  how  such  methods  adapt  and  scale 

Austin  and  Devin  (2003)  speculate  that  old  production  models  for 
software  development  are  no  longer  useful.  Rather,  agile  software 
development  has  the  potential  to  be  “artful  making.” 

They  build  a  framework  using  the  analogies  of  theatrical  production, 
extending  beyond  surface  collaboration  to  the  on-cue  innovation  that 
theater  companies  routinely  achieve. 
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The  Future:  Emergence 


Dee  Hock  (1999)  has  characterized  the  organization  of  the  Zisfcentury 
organization  as  a  chaord. 

Primary  science  of  the  next  century:  the  study  of  emergence  and  complex 
self-organizing,  nonlinear,  adaptive  systems,  often  referred  to  as 
complexity  theory  or  chaos  theory  (De  Geus  1997;  Wheatley  2001). 
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Living  systems  "arise  and  thrive  on  the  edge  of 
chaos  with  just  enough  order  to  give  them 
pattern,  but  not  so  much  to  slow  their 
adaptation  and  learning." 

■  j  T  1 

This  rel^embles  the  challenge  for  agility. 


c 


r 

K 

K 


A 


^  Dogs  this  represent  the  larger  paradigm  shift  of 
"  which  agile  methods  are  a  part? 


Emerging  Systems:  The  Interconnectedness  of  All  Things 
http://www.imaginify.org/complexitygallery/complexity.html 
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Chaiienges,  Diiemmas,  &  Conundrums 


Achieving  the  future  state  is  a  challenge  in  itself — enhancing, 
adapting,  applying,  and  scaling  agile  approaches 

Areas  of  controversy 

•  process 

•  discipline 

•  governance 
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Process 


Agile  methods  vs.  process-intensive  or  monumental  models  like  the 
SW-CMM®  framework  (Highsmith  2000). 

Paulk  (2001)  looks  at  how  such  approaches  are  not  entirely  at  odds 
and  illustrates  how  a  development  group  following  extreme 
programming  might  simultaneously  embrace  CMM,  at  least  up  until 
Level  3.  At  Level  3,  the  approaches  diverge. 

Boehm  (2002)  and  Boehm  and  Turner  (2003)  argue  that  agile  and 
plan-driven  methods  each  have  a  “home  ground.”  They  emphasize 
balance  and  attempt  to  make  a  case  for  hybrid  strategies. 

The  split  between  process  and  agility  has  become  a  lightning  rod, 
reinforcing  entrenched  positions  and  a  strict  drawing  of  lines. 
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Misconceptions  about! 


Process 


don't  need  process 


I  have 

-  really  good  people 

-  advanced  technology 

-  an  experienced  manager 

Process 

-  interferes  with  creativity 

-  =  bureaucracy  +  regimentation 

-  hinders  agility  in  fast-moving  markets 

-  is  only  useful  on  large  projects 


_lt  1 1  \/\xr“inl<:le  m 
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Agiie  or  Pian-Driven? 


Agile  Methods 

•  rely  on  tacit  knowledge 
embodied  on  team 

•  premium  developers 

•  dedicated  customers  w/ 
knowledge  of  full  span  of 
application 

•  turbulent  environment,  constant 
change 

•  requirements  are  emergent 

•  tightly  coordinated  teamwork 
needed  to  succeed  becomes 
increasingly  difficult  beyond  15 
or  20  (Constantine  2001) 


Plan-driven  Methods 

•  invest  in  process  &  product 
plans;  major  milestones 

•  compensate  for  customer 
shortfalls  via  use  of 
architecture  review  boards  and 
independent  expert  project 
reviews 

•  requirements  can  be 
determined  in  advance,  or  via 
prototyping;  requirements 
remain  relatively  stable 

•  vital  for  stable,  safety  critical 
embedded  software 
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Discipiine 


Rakitin  (2001)  takes  a  skeptical  view.  He  sees  values  on  the  right  as  essential, 
while  those  on  the  left  serve  as  easy  excuses  for  irresponsibly  throwing  code 
together. 


Individuals  and  interactions  over  processes  and  toois 

Translation:  Talking  to  people  gives  us  the  flexibility  to  do  whatever  we  want 
in  whatever  way  we  want  to  do  it.  Of  course,  it’s  understood  that  we  know 
what  you  want — even  if  you  don’t. 

Working  software  over  comprehensive  documentation 

Translation:  We  want  to  spend  all  our  time  coding.  Real  programmers  don’t 
write  documentation. 

Customer  coiiaboration  over  contract  negotiation 

Translation:  Let’s  not  spend  time  haggling  over  the  details,  it  only  interferes 
with  our  ability  to  spend  all  our  time  coding.  We’ll  work  out  the  kinks  once  we 
deliver  something. 

Responding  to  change  over  foiiowing  a  pian 

Translation:  Following  a  plan  implies  we  would  have  to  spend  time  thinking 
about  the  problem  and  how  we  might  actually  solve  it.  Why  would  we  want  to 
do  that  when  we  could  be  coding? 
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Discipiine 


Agile  proponents  see  CMM  framework  as  engendering  bureaucratic, 
prescriptive  processes,  fostering  a  command  and  control  environment 

More  subtle  definitions  of  discipline  have  not  yet  been  brought  to  bear. 

Under  the  auspices  of  agility,  there  must  be  some  structure,  order  and 
organization. 

•  We  know  that,  in  actuality,  it  takes  time  to  speed  up,  unless  you  are 
simply  cutting  things  out.  (Smith  &  Reinertsen  1998) 

•  By  extension,  it  takes  discipline  to  be  agile. 

There  are  new  approaches  to  experimentation  and  frameworks  such 
as  artful  making — ^where  the  emphasis  is  on  a  method  of  control  that 
accepts  wide  variation  within  known  parameters. 

What  kind  of  discipline  contributes  in  the  agile  environment? 
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Leadership  vs.  Management 

•  “No  one  has  yet  figured  out  how  to  manage  people  effectively  into 
battle;  they  must  be  led”  --John  Kotter,  What  Leaders  Really  Do 

•  Leadership  is  about  helping  people  cope  with  change,  while 
management  is  about  coping  with  complexity.  Leaders  set 
direction,  managers  plan  and  budget.  Leaders  align  people, 
managers  organize  and  staff.  Leaders  nnotivate,  managers 
control. 

•  Shusa,  or  scrum  master  vs.  traditional  manager 

We  are  faced  with  conflicting  models — one  for  development  which  can 
be  agile,  and  one  for  project  management,  for  oversight,  and 
monitoring. 


©  2005  Carnegie  Mellon  University 


35 


~ —  Carnegie  Mellon 

Software  Engineering  institute 

Governance 


Development  vs.  Acquisition 

Acquisition  program  managers  have  expressed  interest  in  their 
development  teams  using  agile  methods.  However,  they  are  at 
a  loss  to  identify  appropriate  mechanisms  that  could  be 
employed  for  monitoring  and  oversight  of  systems  development. 

It  is  naive  to  assume  that  oversight  is  antithetical  to  agile 
approaches.  Once  again,  we  are  challenged  to  reach  beyond 
comfortable  and  convenient  walls  to  explore  new  territory. 
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Conciusion 


Speed,  Quality,  Processes,  Technical  Solutions,  Principles, 
Business  Solutions,  and  Balance 

Agility  in  software  development  has  implications  for 
organizational  agility.  The  shift  to  agile  methods  and  models 
signals  a  larger  transformation  in  the  workplace  and  the 
organization  of  the  21st  century. 

This  transition  state  is  turbulent,  marked  by  continuous  change. 
No  clear  or  easy  solutions  have  resulted. 

The  transformation  is  a  work  in  progress,  and  by  no  means 
complete.  To  be  realized,  it  invites  investigation  across  a  range 
of  disciplines  and  initiatives. 
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Agiie  Approaches 


Jim  Highsmith  identifies  seven  agile  software 
development  ecosystems 

1.  Scrum 

2.  DSDM  (Dynamic  Systems  Development  Method) 

3.  Crystal  Methods 

4.  FDD  (Feature  Driven  Development) 

5.  Lean  Development 

6.  XP  (extreme  Programming) 

7.  Adaptive  Software  Development 
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Agiie  Methods  (Theoreticai) 


The  amount  of  specific  vs.  general  guidance  is  key: 

Scrum,  DSDM,  FDD,  and  XP  give  specific  guidance.  Lean 
Development,  Adaptive  Software  Development,  and  Crystal  Methods 
present  a  theoretical  basis  for  agile  practices. 

Theoretical  methods 

•  Crystal  concentrates  on  communication  and  varying  practices 
based  on  project  size  and  risk. 

•  Agile  Software  Development  focuses  on  emergence 

•  Lean  Development  emphasizes  traditional  lean  concepts  of  value 
and  flow. 

•  All  three  emphasize  the  primary  importance  of  the  development 
team.  None  of  these  three  methods  focus  on  specific  practices,  so 
they  do  not  find  themselves  in  conflict  with  the  four  agile  methods 
that  offer  more  specific  practices,  or  with  each  other. 
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Other  Agiie  Methods 


•  Scrum,  DSDM,  FDD,  and  XP  offer  specific  practices,  generally 
expected  to  be  followed  as  a  package  until  one  is  expert  enough  in 
the  method  to  modify  practices. 

•  DSDM  and  Scrum  focus  on  project  management  and  are  agnostic 
about  the  underlying  technical  approach.  Both  emphasize  business 
value,  fixed  time  boxes,  significant  customer  involvement, 
developing  high  priority  items  first,  and  stopping  when  you  run  out 
of  time. 

•  DSDM  is  the  higher  ceremony  approach,  while  Scrum  spends  less 
time  on  project  initiation  activities. 

•  FDD  is  a  complete  approach  covering  both  technical  issues  and 
project  management.  It  is  different  from  the  other  agile  practices 
because  it  does  not  advocate  common  code  ownership,  but  rather 
assigns  class  ownership.  This  rather  large  technical  difference 
underlies  many  of  its  other  differences  from  other  agile  practices. 
Because  of  its  comprehensiveness  and  different  technical 
approach,  FDD  would  not  co-exist  well  with  other  agile  approaches, 
but  would  be  used  separately. 
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•  Scrum  and  XP  are  often  used  together  because  their  practices  are 
more  or  less  disjoint: 

•  Scrum  focuses  on  project  management  while  XP  focuses  on 
developer  practices.  Both  of  these  approaches  are  often  billed  as  a 
complete  set  of  practices  that  are  supposed  to  be  used  without 
modification,  at  least  until  the  users  become  skilled  enough  to 
make  appropriate  changes. 

•  However,  when  used  together,  a  few  differences  have  to  be 
resolved,  including  recommended  iteration  length,  specific  planning 
details  including  release  planning  and  stories  or  backlog  items. 

•  For  all  of  their  differences,  one  interesting  difference  is  the  way 
leadership  is  viewed  in  the  various  practices. 

Agile  Ecosystems  A  Position  Paper  for  the  Workshop:  Are  Agile  Methodologies  Really 

Different?  Mary  Poppendieck. 

http://www.coldewey.eom/publikationen/conferences/oopsla2003/MaryPoppendieck.pdf 
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Boehm,  Barry.  (2202)  Get  ready  for  agile  methods,  with  care.  IEEE  Computer,  pp.  64-69 
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Process  n.  1.  a  continuing  development 
involving  many  changes  2.  a 
particular  method  for  doing  something, 
usually  involving  a  number  of  steps  or 
operations.  (Webster’s,  1976) 

IEEE  —  a  sequence  of  steps  performed 
for  a  given  purpose 

CMM  —  a  set  of  activities,  methods, 
practices,  and  transformations  that 
people  use  to  develop  and  maintain 
software  and  the  associated  products 
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Why  do  we  need  process? 


Enables 

•  repeatability 

•  insight,  oversight 

•  control,  tracking 

•  measurement 

•  improvement 

•  training 
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Behavior  under  Stress 


In  times  of  stress,  Process  may  be: 

•  abandoned  PANIC 

•  abbreviated 

•  tailored 

PLANNED 
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Ditch  technical 
reviews 


Behavior  under  Stress 


The  difference  between  PANIC  and 
PLANNING  is  understanding  risks. 

First  plan,  then  build,  then  document  the  process. 
Only  then  can  you  tailor  a  process 


Tailoring  is  the  result  of  thoughtful 
abbreviation  of  processes. 

Tailoring  takes  into  account: 

-  Tradeoffs:  identify  what  program 
goals  are  more  critical 

-  Contingency  planning:  work  out  what 
to  do  under  various  conditions  of 
program  stress 
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Software  Engineering  institute  (SEi) 
Overview 


DoD  R&D  Laboratory  FFRDC 


Mission:  Advance  the  state  of  the 
practice  of  software  engineering  and 
software-intensive  systems 
acquisition 

Location:  A  college-level  unit  of 
Carnegie  Mellon  University  with 
principal  locations  in  Pittsburgh,  PA 
and  Arlington,  VA 


Created  in  1984,  based  on  a  recommendation  of  a  DoD  Joint 
Task  Force,  chaired  by  the  Deputy  Under  Secretary  of  Defense 
(R&AT) 
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